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Introduction 


This paper discusses the design of a strawman Interplanetary Cubesat Mission based on the parameters 
of the ongoing Juno Mission to Jupiter. That mission put a large spacecraft into Jupiter orbit. The 
approach presented here has a quantity of Cubesats as the primary payload. There is a large 
“Mothership” which enters Jovian orbit, and dispenses various Cubesats, acting as a store-and-forward 
communications relay back to Earth. The number of Cubesats is determined by the outlines (size, mass, 
power) of the mothership. We baselined the comparable numbers for the Juno spacecraft. With this 
scenario, we can include 333 3U Cubesats, with a large number of different instruments and sensors. 
How the various spacecraft interact on this mission will be outlined in the paper. 

The Authors 

Mr. Stakem has been interested in rockets and spacecraft since high school. He received a Bachelor’s 
degree in Electrical Engineering from Camegie-Mellon University in 1971, where he was a member of 
the Applied Space Sciences group. His first job was for Fairchild Industries, then building the ATS-6 
spacecraft. Wernher von Braun joined Fairchild as Vice-President of Engineering during this time, so, 
technically, Mr. Stakem was once a member of the von Braun Team. Specializing in support of 
spacecraft onboard computers, he has worked at every NASA Center. He supported the Apollo-Soyuz 
mission with the ATS-6 communications satellite. He received Master’s degrees in Physics and 
Computer Science from the Johns Hopkins University. He has taught for Loyola University in 
Maryland, Graduate Department of Computer Science, AIAA, The Johns Hopkins University, Whiting 
School of Engineering, and Capitol Technology University. 

He served for several years as a Mentor for NASA, Goddard Space Flight Center's Engineering 
Bootcamp, which brought together international teams of students to work on real projects. This 
resulted in the deployment of the Grover (Greenland Rover), a large “satellite” operating at zero 
altitude. It collects data on the thickness of the Greenland Ice Sheet. 

He has also been active in the summer Cubesat program at Capitol Technology University, teaching 
classes and mentoring student projects. This paper is an outgrowth of the Summer, 2016, program. 

The mechanical design and analysis of the Pinesat mothership is the work of Rodrigo Santos Valente 
Da Costa, of Universidada Federal do Rio Grande do Sul, the Johns Hopkins University, and Capitol 
Technology University. 

The research on Cubesat Swarm Communications and the design and implementation of the Electronic 
Data System is the work of Aryadne Rezende and Andre Ravazzi, of the Department of Computer 
Science of the Federal University of Uberlandia, Minas Gerais, Brazil. 

The communications design is the work of Vishnu Chandrarasenan, a Graduate Student in the 
Telecommunications Program, Department of Electrical and Computer Engineering, University of 
Maryland. 

We are continuing to refine the concept in a colloborative online environment, 
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The Target, Jupiter 

Jupiter, the largest planet in our solar system, has 67 known moons, and 6,000 Trojans. Trojan asteroids 
are in orbit, in front and behind (at the 4 th and 5 th Lagrange points) in the same orbit as the primary’s 
around the sun. The one-way light travel time between Jupiter and Earth range from 33-53 minutes. 

The Jovian system is a series of complex, non-homogeneous environments. The radiation environment 
of Jupiter is intensive in the trapped radiation belts, the equivalent of Earth's Van Allen belts. They are 
thousands of times stronger, however. Jupiter is a big spinning electromagnet, whose outer core is 
liquid metallic hydrogen. 

Jupiter’s Magnetic field is 20,000 times that of Earth. This would allow for the use of a conductive 
tether to generate electricity. The cost is reducing the orbital kinetic energy, which would require 
reboosts. We did not explore this option, at this time. 

The Galileo spacecraft entered Jovian orbit in 1995, and returned data on the planet and the four 
Galilean moons until 2003. Three of the moons have thin atmospheres, and may have liquid water. The 
moon Ganymede has a magnetic field. Galileo was in the right place at the right time to see the comet 
Showmaker-Levy-9 enter the Jovian atmosphere, and launched an atmospheric probe, ft was sent on a 
terminal journal into Jupiter's atmosphere in 2003 to protect a possible ocean under the ice crust on the 
moon Europa. It had completed 34 Jupiter orbits. The spacecraft used a pair of RTG's providing 
around 500 watts. 

The Cassini spacecraft, on its way to Saturn, did a Jupiter flyby in 2000 and captured a large number of 
images. Cassini is still conducting its primary mission at Saturn at this writing. It uses RTG's for power 

The Juno Mission 

The $1.2 billion ($ 10 9 ) Juno mission to Jupiter arrived 5 years after launch, and settled in to begin its 
observations. The spacecraft was launched in August of 2011, and arrived in July 2016. It was placed in 
Jupiter elliptical polar orbit, and will de-orbit into Jupiter in February 2018. This is to ensure burn-up 
of the spacecraft to avoid any biological contamination of Jupiter or its moons. It is scheduled to make 
37 orbits. The orbit was chosen to minimize contact with Jupiter's intense trapped radiation belts. Juno's 
sensitive electronics are housed in “the Juno radiation vault,” with 1 cm thick titanium walls. Juno will 
have available to it some 420 watts of power, from the solar panels, which cover 72 square meters. 

The spacecraft weighs over 1,500 kg. It uses 3 solar panels of 2.7 x 8.9 meters size These will be 
exposed to about 4% of the sunlight that it would have at Earth. The spacecraft left Florida on an Atlas- 
V-551 vehicle. The perijove, or closest distance to the planet was planned to be 4,200 km. The highest 
altitude at apojove is 8.1 million kilometers. 

The mission includes infrared and microwave instruments to measure the thermal radiation from 
Jupiter's atmosphere, with particularly interest in convection currents. It's data will be used to measure 
the water in Jupiter's atmosphere, measure atmospheric temperature and composition, and track cloud 
motions. The mission will also map Jupiter's magnetic and gravity fields. It is expected to probe the 
magnetosphere in the polar regions and observe the auroras. 

Juno uses a bi-propellant propulsion system for adjustments and insertion manoeuvres, and a 
monopropellant system for attitude control. 

Communication uses an X-band to support 50 Mbps of data to Earth. The spacecraft will be 
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constrained to 40 Mbytes of camera data per 11-day orbit period. 


Communications 

NASA's Deep Space Network consists of three antenna sites spaced around our planet. It supports deep 
space missions for NASA and other entities. It is managed by the Jet Propulsion Lab (JPL) in Pasadena, 
California. The nearest station to JPL is at Goldstone, in the desert to the east. Two other stations, in 
Spain and Australia are spaced about 120 degrees apart on the globe from Goldstone. The DSN started 
operations in the 1960's, and is heavily oversubscribed, supporting numerous deep space missions, 
including Juno. 

Several approaches to communication with spacecraft at a large distances from Earth, and examining 
other planets, have been defined. The Interplanetary Internet implements a Bundle Protocol to address 
large and variable delays. Normal IP traffic assumes a seamless, end-to-end, available data path, 
without worrying about the physical mechanism. The Bundle protocol addresses the cases of high 
probability of errors, and disconnections. This protocol was tested in communication with an Earth 
orbiting satellite in 2008. It is derived from the mobile data protocols used with cell towers in terrestial 
applications. 

As we get farther from Earth, the Cubesat's small antennas, and relatively low power, means we have to 
get clever with communications. There will be limited bandwidth. This was the case with APL's 
Horizon's spacecraft at Pluto - It takes more than 16 months to transmit all the data back from the 
encounter. 


The Pinesat alternative 

This strawman mission was used as a teaching tool by the author in a Cubesat Engineering and 
Operations course in the Summer of 2016. The parameters of the Juno mission were used to bound the 
problem, and examine the feasibility of replacing one large exploration spacecraft with a swarm of 
smaller ones. Work continues in a collaborative manner, globally. 

One advantage of the carrier is, like the Shuttle, payloads can be tested before deployment Known bad 
units can be left in place, or discarded into Jupiter's atmosphere. The carrier is designed to be modular 
and adaptable. It is scalable to 100's or 1,000's of Cubesats. 

The Pinesat mechanical design is straightforward. The name comes from the fact that the dispenser 
resembles a pine tree. The Pinesat dispenser has a central hexagonal tube, with the propulsion and 
electrical power section at the launch vehicle interface end. The avionics and data storage are located in 
the nose of the vehicle while p-pod's (Poly-Picosat orbital deployer) are distributed radially along the 
central tube. This allows for longitudinal deployment. We baselined having 333 P-pod dispensers, each 
with a 3-U cubesat inside. The number of p-pods per layer and the total number of layers are scalable 
within the parameters of the launch vehicle and fairing. The Pinesat Jupiter mission results in a 
spacecraft approximately 9.2 meters long by 1.8 m in diameter, with a dry weight of 2,764 Kg, 
assuming 3Kg 3 unit Cubesats. 

The Pinesat will keep a database of Electronic Data Sheets of all the Cubesats. This includes state-of- 
charge, operational status, and instrument complement. This can be updated by a query request from 
the dispenser's main computer. 
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Unlike Earth Cubesat missions, the Cubesats going to Jupiter can have their own propulsion. The big 
limiting factor for them is electrical power. They can't carry solar arrays large enough to make sense. 
They will be dispersed from the carrier fully charged, and operate as long as they can. The electronics 
and software will be optimized to minimize power usage. 

The mothership/dispenser will have a bi-propellant engine for orbit and cruise adjustments, and a 
monopropellant system for attitude control and reaction wheel momentum unloading. 

Pinesat Avionics 

The Pinesat dispenser will have dual redundant, rad-hard flight computers such as the RAD-750's that 
were used on Juno. They are baselined with 256 megabytes of flash, 128 megabytes of DRAM, and 
operate at 200 MHz. A newer concept is to use a Pi-Cluster, a group of Raspberry Pi's, with a rad hard 
Arduino watchdog. It will have sufficient storage for the database of the Cubesats' EDS. It will also 
host an onboard network for communications with the Cubesats when they are onboard, and via radio 
link when they have been deployed. The dispenser vehicle manages the Swarm's communications links 
with Earth. The mothership can also carry instrumentation. And the 334 th “cubesat.” 

Cubesats 

The Cubesats will be 3U in size (30x10x10 cm), with a Raspberry-Pi flight computer, running 
NASA/GSFC's CFS/CFE flight software. They will have a sun sensor and a magnetic field sensor. 
Magnetic torquers may be included. They will have a cold gas propulsion system. Different 
instrumentation will be included on different Cubesats with common busses. These will be deployed by 
the mothership as required, to observe and collect data on targets of interest. 

Ops concept 

The Mothership transports the Cubesats to Jupiter unpowered. Every day or week (tbd), the units are 
powered on, one at a time, and checked for functionality. The onboard database is updated as required. 
The results are sent back to the control center on Earth. 

At Jupiter, the Mothership uses its main engine to enter orbit outside of the ring system. It then orients 
itself in a gravity-gradient attitude, with the solar panels oriented to the Sun. 

After another system check of itself and the Cubesats, the Mothership deploys a series of Cubesat 
scouts on a reconnaissance mission, to seek out areas of interest. The Mothership deploys Cubesats 
with broad spectral sensing. Based on their findings, the mothership will deploy additional Cubesats 
with specific instrumentation to the area of interest. (For example, an advanced thermal imager to an 
area of observed thermal activity). The Cubesats are released in the order of necessity. They will be 
able to adjust their attitude with torquer bars to push against the large Jovian magnetic field. We can 
also include the idea of Cubesat “suicide missions”, where the Cubesat plunges into the ring system, or 
Jupiter's upper atmosphere, and returns data until it is rendered non-functional. 

The Cubesats will: 
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• Conduct radio occultation experiments to better categorize the distribution of particles in the 
rings, by size. 

• Explore the characteristics of the ring systems, including density, size, distribution, and particle 
composition. This can also be conducted with synchronized simultaneous observation from 
multiple observation points. 

• Explore features visible on on the planetary “surface.” 

• Map the Jovian magnetic field and trapped charged particle environment. 

• Be able to respond to targets of opportunity, should they arise, such as the observed plunge of 
comet Shumaker-Levy-3 into Jupiter's atmosphere by the Galileo spacecraft. 

The Cubesat instruments can be expanded beyond that of Juno. Different Cubesat busses will have 
different sensor suites. We have 334 observation platforms, including the dispenser. The mission 
flexibility will be greater, and the system will be better able to respond to unanticipated events and 
opportunities. 

Enabling Technologies 

This section defines the technologies that will be used to implement Pinesat. A subsequent section will 
examine their technology readiness levels (TRL's). 

Better batteries and solar panels 

The batteries and solar panels on the Juno mission are functioning well, and since the Mothership will 
be roughly the same size, we could postulate their use. A steerable array will be needed. Due to 
technology advances, solar cells can be now used out to 5AU, and are getting more efficient. A JPL 
report says they degrade due to radiation damage in 3-5 years. 

Rad-Hard Software 

This is a concept that implements routines that check and self-check, report, and attempt to re-mediate. 
It is an outgrowth of the testing and self-testing of the computers' functionality, with focus on detection 
of radiation induced damage. We know, for example, that one of the tell-tales for radiation damage is 
increasing current draw. At the same time, we monitor other activities and parameters in the system. 
This partially addresses the problem of operating with non-radiation hardened hardware in a high 
radiation environment. 

From formal testing results, and key engineering tools, we can define likely failure modes, and 
possible remediation. Besides self-test, we can have cross-checking of systems. Not everything can be 
tested by the software, without some additional hardware. First we use engineering analysis that will 
help us define the possible hardware and software failure cases, and then define possible actions and 
remediation. None is this is new, but the suggestion is to collect together best practices in the software 
testing area, develop a library of RHS routines, and get operational experience. Another advantage of 
the software approach is that we can change it after launch, as more is learned, and conditions change. 

Rad Hard software is a series of software routines that run in the background on the flight computer, 
and check for the signs of radiation damage. The biggest indicator is an increase in current draw. The 
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flight cpu must monitor and trend it's current draw, and take critical action such as a reboot if it deems 
necessary. The Rad Hard software is a variation on self-check routines, but with the ability to take 
action if needed. It can keep tabs on memory by conducting CRC (cyclic redundancy checks), and one 
approach to mitigating damage to semiconductor memory is “scrubbing,” where we read and write 
back each memory locations (being careful not to interfere with ongoing operations). This can be done 
by a background task that is the lowest priority in the system. Watchdog timers are also useful in 
getting out of a situation such as the Priority Inversion, or just a radiation-induced bit flip. There should 
be a pre-defined safe mode for the computer as well. Key state data from just before the fault will be 
stored. Unused portions of memory can be filled with bit patterns that can be monitored for changes. 
We must be certain that all of the unused interrupt vectors point to a safe area in the code. 

Functions within the RHS include current monitoring as a tell-tale of radiation damage, self-diagnosis 
suite, spurious interrupt test, memory test(s), checksum over code, data corruption testing, memory 
scrub, I/O functionality test, peripherals test, stack overflow monitoring, and a watchdog timer. A 
complete failure modes and effects analysis will be conducted over the flight computer and associated 
sensors and mechanisms, and this will be used to scope the RHS. The systems will keep and report 
trending data on the flight electronics. In most cases, the only remediation will be a reboot. However, 
since the units will have identical configurations, the data will be useful to be able to predict pending 
failures, and to possible correct them. This will be used on the Mothership's and on the Cubesat's 
anticipated RaspberryPi flight computers. 

Dispenser/Mo th ership 

The mothership will be built with standard aerospace products with a Jupiter-mission heritage. We 
expect to be able to use the same batteries and solar panels as the Juno mission, since the Mothership 
will be roughly the same size. The X-band transceiver on Juno would be a candidate for the Earth link. 
Standard p-pod cubesat dispensers are baselined, but the effects of long storage of the CubeSats in the 
dispensers must be studied. The effects of cold welding during the estimated 5 year transit needs to be 
examined closely. 

Inter-unit communications 

Before deployment, the Cubesat flight computers use the network infrastructure of the Mothership to 
communicate. After deployment, a radio solution will be employed. Cubesat to Mothership 
communication can be S-band. It does not necessarily need to implement a delay tolerant protocol, 
since the Cubesats will be “in the vicinity” of the Mothership. 

Communication methodology within the CubeSat network. 

There are two main aspects which is involved in communication within a CubeSat swarm network,the 
Network Topology and the Inter-Satellite Link (ISL). These are explained below, and we expect to use 
CCSDS protocols over the physical links. 

Once a set of CubeSats are deployed, the first challenge will be the initialization of the swarm 
communication network. This includes three main areas of implementation: Addressing, network 
discovery and synchronization. Gossip protocol can be the most appropriate, primarily because the 
underlying network is unstructured in its distribution of nodes. It is a robust way to bring controlled 
network initialization in a large cluster, in a decentralized manner. Each node will send out network 
initialization data to a fixed number of other nodes, where it propagates through the system, node by 
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node like an epidemic vims in a biological community. Eventually, data is propagated to every node in 
the network, creating a global network map with very limited local interactions. 

Additionally, every cluster will have a cluster head, who has the responsibility of streamlining the data 
distribution and associated tasks. Two or more CubeSats in a cluster can be designed to back-up as a 
cluster head, in case the primary one fails. 

The second important point of consideration in an ISL are the limiting constraints, which include the 
satellite’s size and power output. Satellites will exchange two types of data through its communication 
channel: primary observational data, along with secondary data which will include metadata, position 
and localization information along with timing information. 

ISL communication is to be achieved on Ultra High Frequency (UHF). With the clustering and non¬ 
clustering topology, an inter-satellite communication range of 90km to 100km is viable on UHF within 
the power output range of 4-5 W. The next challenge is regarding selection of the ideal antenna and 
communication protocol, keeping in mind the existing power and mobility constraints along with the 
tradeoff between radio power and communication distance. NASA’s Nodes (Network & Operation 
Demonstration Satellite) mission, similar in structure to the Edison Demonstration of Smallsat 
Networks (EDSN) mission, deployed a satellite swarm of CubeSats from the ISS to test inter-satellite 
communication capabilities in 2015. A primary UHF radio was used for crosslink communication, and 
a further UHF beacon radio was used for transmitting real time health information of the satellite. In 
addition to this, position, navigation and tracking information can complement the primary data load. 

Compute cluster of convenience 

Within the system, we will implement co-operative computing, with a goal of reducing downlink 
bandwidth to suite the capabilities of the system, while still returning information of value. This 
approach will be implemented with the Beowulf clustering software, and networking resources onboard 
the mothership. Each p-pod will supply power and a data link to the enclosed Cubesat. Each non- 
deployed Cubesat can participate in a Beowulf-class cluster computer. 

Using a variation of the Beowulf and the intranet of the Mothership, the Cubesats awaiting deployment 
can be linked into a Compute cluster configuration. Each will have the correct software as a compute 
node pre-loaded as part of its Linux operating system. 

The Beowulf software was developed at GSFC to provide a low cost open source solution to linking 
commodity pc's into a supercomputer. The approach has been applied to clusters of small architectures 
such as those that serve as flight computers for Cubesats. As part of the student summer program, we 
demonstrated a 5 node cluster, using Raspbery Pi's. Several 64-node clusters have been constructed. 
These are the size of desktop pc's. Our onboard cluster,unfortunately, becomes less caopable as more 
cubesats are deployed. Cluster computing has two parameters: Compute rate, in instructions/second, 
and data rate, in words/second. Generally, if these are in balance, we get the optimal results. A good 
design point is a balance in MIPS/MHz or GIPS/GHz (measured in instructions per data words). This 
depends, however, on the nature of the problem implemented on the cluster. 

The Beowulf cluster is ideal for sorting and classifying data; an example application is the Probabilistic 
Neural Network. This algorithm has been used to search for patterns in remotely sensed data. It is 
computationally intensive, but scales well across compute clusters. It was developed by the Adaptive 
Scientific Data Processing (ASDP) group at NASA/GSFC. The program is available in Java source 
code. 
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The first Beowulf cluster to be flown in space was built from 20, 206-MHz StrongARM (SA1110) 
processors, and flew on the X-Sat, which was Singapore's first satellite. The performance was 4,000 
MIPS. The cluster drew 25 watts. The satellite was a 100 kg unit, 80 CM cube. The cluster approach 
was used because the satellite collected large amounts of image data (80 GB per day), most of which 
was not relevant to the mission. So, an onboard classification algorithm selected which images would 
be downloaded. For example, cloudy images were discarded, since land images were of interest. The 
key concept demonstrated here was that the compute cluster could reduce downlink requirements by 
pre-processing data in situ. 

Cubesat Swarm 

This section describes a different approach where collections of smaller co-operating systems that can 
combine their efforts and work as ad-hoc teams on problems of interest. Cubesats can be organized in 
Swanns. 

This is based on the collective or parallel behavior of homogeneous systems. This covers collective 
behavior, modeled on biological systems. Examples in nature include migrating birds, schooling fish, 
and herding sheep. A collective behavior emerges from interactions between members of the swarm, 
and the environment. The resources of the swarm can be organized dynamically. 

A driver in space exploration is the shear number of things that needs to be explored, the minor moons 
of the gas giants, and asteroids, numbering in the thousands. We can no longer afford to send dedicated 
single spacecraft mission to all the potential targets in our solar system. Although there are fewer than 
10 planets, and less than 200 moons, there are millions of asteroids, mostly in the inner solar system. 
The main asteroid belt is between Mars and Jupiter. Each may be unique, and some may provide 
needed raw materials for Earth’s use. There are three main classifications: carbon-rich, stony, and 
metallic. Near Earth asteroids are of interest, not only due to the collision potential, but that they may 
be exploitable for their constituent materials. 

The physical composition of asteroids is varied and poorly understood. Ceres appears to be composed 
of a rocky core covered by an icy mantle, whereas Vesta may have a nickel-iron core. Hygiea appears 
to have a uniformly primitive composition of carbonaceous chondrite. Many of the smaller asteroids 
are piles of rubble held together loosely by gravity. Some have moons themselves, or are co-orbiting 
binary asteroids. The bottom line is, asteroids are diverse. 

It has been suggested that asteroids might be used as a source of materials that may be rare or 
exhausted on earth (asteroid mining) or materials for constructing space habitats or as refueling stations 
for missions. Materials that are heavy and expensive to launch from earth may someday be mined from 
asteroids and used for space manufacturing. Valuable materials such as platinum may be returned to 
Earth for a profit. 

Exploring the Jupiter system, the rings and moons, requires a diverse and agile approach. Thus, a 
swarm of small robotic spacecraft with different capabilities can be used, combining into Swarms of 
Convenience to address situations and issues discovered in situ. For this to be enabled, a distributed 
control system for the Cubesat elements is required. It is less efficient to have a central control at the 
mothership. The Cubesats can be given loose instructions, such as fly out 1,000 km and enter the 
atmosphere. Beyond that, what they will do depends on local conditions encountered, and is best 
handled locally. 
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In Swarm systems, the key issues are communication between units, and cooperative behavior. The 
capability of individual units does not much matter; it is strength in numbers. Ants and other social 
insects such as termites, wasps, and bees, are models for swarm behavior. Self-organizing behavior 
emerges from decentralized systems that interact with members of the group, and the environment. 
Swarm intelligence is an emerging field, and swarm robotics is in its infancy. 

An actual “constellation” of 50, 2U and 3U Cubesats was deployed in orbit in 2015. Some were 
released from the ISS, and in coordination with a rocket launch. They collected and telemetered data on 
the lower thermosphere. This was not a Constellation, per se, but 50 units acting on their own, 
reporting back to their home institutions. Universities around the world participated, and built units 
from the QB50 specification. 

The data came from the region below 85 kilometers, which has enough of an atmosphere to impede 
spacecraft. The Cubesats collected data as long as they could, as they were reentering the atmosphere. 
At these altitudes, the rarefied atmosphere can reach temperatures of 2,500 degrees C. It is also a region 
where the dynamics are controlled by atmospheric tides, themselves controlled by diurnal heating and 
cooling. The member Cubesats did not interact with each other, but did do onboard processing to 
reduce downlink bandwidth. 

Onboard databases 

Each member of the Swarm is self-documenting. It carries a copy of its Electronic Data Sheet (EDS) 
description, which can be updated. This defines the system architecture and capabilities, and has both 
fixed (as-built) and variable entries. The main computer in the Mothership has a copy of all 333 of 
these, and can get updates by query. The Mothership also has parameters on each unit's state, such as 
electrical power remaining, temperature, etc. One value of the database is, if the mothership needs a 
unit with a high resolution imager, it knows what unit that is, and whether it has been deployed or not. 
If it has been deployed, it can query the unit on its position and health status. Implementing the EDS in 
a true database has advantages, since the position of the data item in the database also carries 
information. It also allows the use of off-the-shelf database tools. The individual CubeSats have a 
“light-weight” version of the database, while the mothership has a more sophisticated one. All the 
schema's are the same. 

There are two parts of the tables, representing static and dynamic data. Static Data represents the 
hardware and software configuration of the swarm unit. These values are not expected to change during 
the unit's operation. The Dynamic Data table represents the sensors each particular unit has. These 
values can change, and with a timestamp the last values will be kept as a part of the EDS during the 
mission. 

The Mothership is responsible for aggregating all of the Cubesats' housekeeping and science data, and 
transmitting it back to Earth. This is also facilitated by the structure imposed by the database. An Open 
Source version of an SQL database is preferred. The EDS documents will be in XML. 
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Static Dynamic 


Item 
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1 

4 
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1 

tbd 
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Clock 

MHz 
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tbd 

Temperature 
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mA 
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66 
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14 

4 
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mA 
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tbd 
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18 

512 

SRAM 
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Electronic Datasheet Simple Example 


The system proposed in this project has the architecture shown in the figure: 



System Architecture 

The swarm member shown in Figure 1, is a class that has a relationship with four more classes. The 
swarm member is an entity that has dynamic data and static data data types to keep its configuration, 
housekeeping, and sensors information. This class also uses general_server and client classes to handle 
received requests (general_server) and to send requests to other swarm members (client). 

TRL assessment 

This section discusses the estimates of the Technology Readiness Levels of the various mission 
components. 

The following items and subsystems will be copied from the Juno mission, and are at TRL-9: 

Solar panels, power distribution unit, Flight Computers,, batteries, X-band transceiver and high gain 
antenna, bi-propellant LEROSlb main engine for trajectory correction, monopropellant attitude control 
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thrusters. 

Atlas-V-551 launch vehicle, TRL-9, seven launches to date, including one to Jupiter 

For the proposed new parts, we assessed the technology, and defined these TRL levels. It has to be 
taken into account that a TRL derived for an Earth mission needs to be adjusted downward for a long 
cruise, and for operation at Jupiter. The Juno spacecraft parts are considered TRL-9 for operations at 
Jupiter. 

• Inter-cubesat communications - TRL-3. 

• Mother ship to cubesat communication - TRL-3. 

• Cubesat - TRL-9 for Earth Missions, TRL-tbd for Jovian environment. 

• Core Flight System/Core Flight Executive software - TRL-9 

• Raspberry Pi flight computer - TRL-9 for Earth missions, TRL-7 or less for Jupiter 
environment. 

• P-Pod dispenser - TRL-9. (TRL-7 for operation at Jupiter, after a long cruise). 

• Computer cluster - TRL-7. 

• Beowulf clustering software - TRL-9. 

• PNN algorithm - TRL-5. 

• Rad-hard software - TRL-3. 

• Onboard EDS relational database - TRL-7. 

• Onboard testing of Cubesats before deployment - TRL-4. 

• Cubesat Swarm (Cubesat Constellation, 50 units in Earth Orbit, 2015; Indian launch of 104 
Cubesats, February 2017) - TRL-9. 

In all, we found no major problems to the multi-Cubesat approach in this quick assessment, and, in 
fact, some major advantages. At the same time, a topic of further research is the quite smaller Chipsats, 
a swarm of which could be released from a Cubesat. There are just too many interesting places to visit 
in our solar system. 

Future work will include a study of a Pinesat-type architecture targeted to the icy giants, Uranus and 
Neptune. We are thinking of a Pinesat that is actually a dual unit, where one goes to Neptune and the 
other continues to Uranus. The combined size and weight would be less than the Jupiter Pinesat, and 
we can no longer count of the mothership getting enough electric power from solar panels at those 
distances. An easier project would be exploring the asteroid belt using the GSFC Autonomous Nano 
Technology Swarm (ANTS) concept. This would use less overall control from the Mothership, and 
more autonomy at the individual cubesat level. We are also considering the use of a Cubesat Swarm to 
the Asteroid Belt. 
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